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FIELD OF INVENTION 
The present invention relates to process and systems for manufacturing. In particular, 

y 

the present invention relates to an integrated characterization and scheduling process and 



system for wafer fabrication. 



0 



BACKGROUND OF THE INVENTION 
The current, highly competitive/ semiconductor market is forcing semiconductor 
companies to remain competitive inyrerms of productivity and lead time to market. 
Competitive semiconductor manufacturing companies focus on reducing manufacturing lead 
time while maintaining or increasing production output. Reducing manufacturing lead-time 
is accomplished by reducing Work In Process ("WIP") to the limit where manufacturing lead 
time is reduced but production output is not decreased. Manufacturing lead time will also be 
reduced when variation in the line is reduced. The less the variation in the line the shorter 
that cycle time caiyfce reduced. 

Streamlining WIP and reducing lead time is usually accomplished by efficient 
scheduling ana dispatching of lots to be performed to reduce the amount of time each lot 
waits at a particular station. One known scheduling and dispatching solution is to use 
simulation techniques. Simulation based scheduling provides the benefit of testing the 
scheduling rules in the simulation environment before the scheduling rules are implemented. 
Simulation based scheduling also provides an integrated system between simulation and the 
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scheduler functions in order to timely evaluate and implement scheduling rules and 
scheduling parameter changes. / 

A weakness found in many prior art simulation projects is the obsolescence of data 
used by the simulation model. Wafer fabrication, for example, involves complex dynamic 
production systems. The measurement of their capacity and performance such as lead time 
and wafer output is not accurate enough if a solution capable of modeling the dynamic 
fabrication conditions and variance in the system is not used. The main problem is that 
building a complete fabrication simulation model manually is a daunting task that requires 
many man hours and coordination between many personnel to finish the task timely before 
the model, i.e., logic and data, become obsolete. Also of note is that the maintenance of the 
simulation models is complex/and expensive. 

Traditional system/integration efforts have focused on using mapping programs in 
programming languages such as FORTRAN or C, but these systems are not very flexible to 
user required changes in output and input of the mapping program. Others have tried 
developing a dynamic Manufacturing Execution System ("MES"), but MES do not have all 
the data and logic required to build a valid fabrication simulation model. The main purpose of 
a MES is torexecute processes to perform the actual manufacturing functions. Additional 
data and logic must be added to augment the database of the MES. 

/Fox example, just-in-time ("JIT") pull production systems use Kanban cards to tie 
process flow segments and communicate the amount of products to be pulled to the next 
process flow segment called a Kanban stage. This is usually implemented with a manual 
siystem of cards called Kanbans and wall magnet boards to track progress. In a large 
fabrication facility with many re-entrant points in the process and many products being 
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manufactured at the same time requires high amounts of human resourcesao update and 
maintain the Kanban system. Some have implemented Kanban using^equipment type. That 
is, instead of grouping consecutive process flow steps to make aitanban stage to control a 
work-in-process ("WIP") along the process flow, the Kanban by equipment type is aimed to 
control the WIP at each equipment type. / 

SUMMARY OF THE INVENTION 
The present invention relates to an integrated characterization and scheduling system 
for fabrication production systems such as /wafer fabrication. In particular, the present 
invention is directed to a method and system for designing virtual Kanban systems for use 
with manufacturing execution systems. According the present invention, a system for 
designing Kanaban system includes means for defining a Kanban model based on operating 
parameters such as required Deduct output quantity and required manufacturing lead time. 
Then a simulation of the Kanban model is performed to calculate star and end times of each 
Kanban stage as well as/the number of cards needed in each Kanban stage. 

/ BRIEF DESCRIPTION OF DRAWINGS 
The features and inventive aspects of the present invention will become more apparent 
upon readino^the following detailed description, claims, and drawings, of which the following 
is a brief description: 

Figure 1 is a schematic diagram of an integrated characterization and scheduling 
system of the present invention. 

/ Figure 2 is a block diagram of a functional overview of the present invention. 
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Figure 3 is a block diagram of an offline simulator subsystem of tWpresent invention. 
Figure 4 is a block diagram of a file extraction procedure of thj^ present invention. 
Figure 5 is a sample of a simulation/scheduler screen. / 

Figure 6 is a block diagram of an online applied scheduler subsystem of the present 
invention. / 

Figure 7 is a sample of a machine tact modeler screen. 

Figure 8 is a block diagram of the machine tact modeler of the present invention. 
Figure 9 is a sample of a Kanban worksheet screen. 

Figure 10 is a block diagram of the Kanban design module of the present invention. 



As shown in Figure/, an integrated scheduling system of the present invention 
includes manufacturingykecution system 20, autoscheduling system 22, and common 
database 24, all interconnected by data bus 26. Other network controllers 28 may be attached 
to data bus 26. Autoscheduling system 22 includes scheduler database 30, online scheduling 
workstation 32^md offline simulator workstation 34. Scheduler database 30 stores 
production models for simulation as well as data extracted from manufacturing execution 
system 20yfo be used for the simulation. The stored information includes Tl and T2 
parameters, lot status, machine tact (time standard), and Kanban worksheets . Online 
scheduling workstation 32 is used during automated operation of autoscheduling system 22 to 
vifw and perform manual corrections to the parameters to sent to manufacturing execution 
/ystem 20. Front-end client application software is used to provide a graphical user interface 
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("GUI") to allow a user to manage and display all the parameters stored in^cheduler database 
30. Offline workstation 34 is used to create and manage production nrodels used by 
autoscheduling system 22 to create schedules to be used by manufacturing execution system 



As shown in Figure. 2, the integrated schedulins^system of the present invention has 
two parallel modes of operation: offline simulation,and online scheduling. Offline simulation 
mode is accomplished through offline simulato/subsy stern 36. During offline work, the 
objective is to perform studies following a^Plan, Do, Check, Act" ("PDCA") cycle. At the 
beginning of the planning cycle, offlineysubsystem 36 helps in the preparation of feasible 
production plans that will meet required fabrication performance measures. Once a plan is 
established, the focus is shifted to monitoring progress of plan versus actual performance and 
take corrective action if a deviation from plan is observed. 

For example, during offline operations, production team 38 brainstorms to propose 
production control loaic in terms of model parameters and scheduling rules to develop a 
production model mat achieves desired fabrication performance measures such as wafer outs 
and reduced cycfe time. The proposed model is entered into offline simulator workstation 34 
through user^riendly graphical user interface, and a simulation run on the entered model is 
performedyfo obtain a performance prediction of the proposed model. During the simulation 
run, actiial fabrication data extracted from manufacturing execution system 20 is used to 
evaluate the simulated model. 

/ Based on the simulation results, any logic or parameter that improves the performance 
of the production system towards the goal becomes part of a model that will be used for 
'production planning and short-term scheduling dispatch. Logic or parameters that do not 
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improve production performance is returned to the production team for re-evaluation and 
revision. This process is repeated until an acceptable model is developecLand the parameter 
characterization is stored in a temporary database 40 inside offline simulation workstation 34 
until the model is loaded to scheduler database 30. A more detailed diagram of offline 
subsystem 36 is shown in Figure 3. / fr J 



Online scheduling mode is accomplished througn online applied scheduler subsystem 
42. During online scheduling mode, the process of treating dispatch schedules for 
manufacturing execution system 20 is performedautomatically. The production model 
created using offline subsystem 36 is loaded/from temporary database 40 to scheduler 
database 30. Also within scheduler database 30, most recent parameter information from 
manufacturing execution system 20, /,g., Tl, T2, and lot status, is stored therein and 
constantly updated. A "Tl" dowmoad extracts static information such as parts, equipment, 
and process routing information. A "T2" download extracts status data including work-in- 
progress ("WIP") status, equipment status, and preventive maintenance task schedule and 
status. / 

The front-en4 client application responsible for managing information in scheduler 
database 30 is also responsible for performing data downloads. As shown in Figure 4, a 
front-end client application polls at an interval of 15 seconds for arrival of completion file 
flags. If a yi flag is found, the front-end client automatically imports the data into scheduler 
databaseyQO. Upon completion of the import the system goes back to polling. If a T2 flag is 
foundyahe front-end client automatically imports the data into scheduler database 30 and then 
augments the imported data with data residing in the database to export the required data for 
the simulation run. 
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Once a production model is loaded into scheduler database 30 ancLtne data from 
manufacturing execution system 20 is downloaded, a command is sept to a queuing program 
which start the simulation run automatically. If more than one command is received, the 
queuing program run the simulations sequentially in the orcter the commands are received. 
Simulation engine in scheduler 32 runs a simulation usitfg the loaded model, dowloaded 
parameter information such as Tl and T2 parameter^ machine tact information, and Kanban 
worksheets stored in scheduler database 30. 

Upon successful completion of the simulation run, scheduler 32 outputs schedule of 
event to occur in manufacturing execution system 20. This schedule is imported back into 
scheduler database 30. A dispatch list on the current lot status is created from this schedule 
reflecting the current conditions hi manufacturing execution system 20. 

On a real time basis, a Jot status table is maintained in scheduler database 30 to keep 
the current status of each product lot pending in manufacturing execution system 20 at any 
given time. In this way/the lot status in scheduler database 30 is a mirror image of lot status 
in manufacturing execution system 20. Updates of lot moves into and out of a process step 
are sent by manufacturing execution system 20 through bus 26 and directly inserted into 
scheduler database 30. A database procedure running in scheduler database 30 processes 
each inserted: event as soon as they arrive to insure updates of lot status information. 

The created schedules are also sent via graphical user interface to guidance terminals 
44 for monitoring purposes. Dispatch schedules are updated in scheduler database 30 with 
every lot move in real time. A lot moving from a running status to a waiting at next process 
step status picks its assigned station and scheduled start time before updating the lot status 
information used in dispatch. If an unscheduled event makes the schedule significantly 
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obsolete, for example, a supervisor has an option of re-creating the sonedule manually from 
any of guidance terminals 44 before uploading to manufacturina^execution system 20. Figure 
5 shows a sample graphical user interface screen for monitoring or modifying information 
into the system. A more detailed diagram of online subsystem 42 is shown in Figure 6. 

Machine Tact (time standard) Modeler 

As mentioned above, scheduler database has stored thereon machine tact (time 
standard) information. Since time standards are used by other systems in a fabrication 
system, they must be stored in an oper/database accessible to other systems. Online 
subsystem 42 of the present invention includes a machine tact (time standard) modeler (not 
shown) for modeling time standards customized for a particular system. 

The machine tact modeler of the present invention quickly matches and merges 
process times into the pro/ess steps before the routings are sent to scheduler 32. The machine 
tact modeler defines time standards as a function of process parameters and equipment 
parameters. For example, if a process parameter such as temperature, pressure, etc. and an 
equipment parameter such as equipement brand name, model, etc. are entered, online 
subsystem 42 calculates and suggests time stand to use for those times that are not likely to 
have large variations. In this way, the machine tact modeler of the present invention provides 
the times /cheduler 32 need for accurate simulation runs, schedules, and results. Maintaining 
the macmine tact data in scheduler database 30 ensures that the simulator and scheduler 
always use the latest machine tact measurements and the machine tact data is managed 
through the front-end client application. Figure 7 shows a sample graphical user interface 
sfcreen for monitoring and modifying machine tact information. 

8 
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The following describes the process and parameters of the marine tact modeler in 
detail with reference to Figure 8. 

TACT Processing 

There are several components to the TACT feature. 



TACT Definition 



TACT Formula 



The TACT Definition window manipulates the values in the TACTdef 
table. The TACT Definition window displays a join of the TACTdef, 
TACTformuladef arja stnfamdef tables but can alter only values in the 
TACTdef table. 




The ptimey/setup, unsetup and lap times are calculated using formulae 
defined/n the TACTformuladef table which is maintained by the 
TAC>r Formula Definition window. 



Stnfam Definition 



The TACT Definition window determines which formula to use for 
each TACT by accessing the stnfamdef table which specifies the 
formula to be used for each stnfam. 



TACT record keys 

Tl/e TACTdef and TACTformuladef tables are not model dependent. The stnfamdef 
table is/model dependent. The stnfam definition for the current model will be used to 
determine the TACT formula. 
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Each TACT record has a usage flag which can be set to PRODUCTION^ NEW, 
SAVE. A given record (unique over the keys) can only appear once wittymc usage flag or 
PRODUCTION or NEW. i.e. if there is a PRODUCTION record, th/e cannot be a NEW 
record. There may be as many records as desired with the usage/nag of SAVE whether or not 
there is a PRODUCTION or NEW record. 

When a record is generated automatically using the Xdd Records function that scans the 
routes, the new records are given a usage flag okNEW. 

When a route is exported to AS each^step will obtain its TACT times from the 
corresponding TACT record with a usage>Tlag of PRODUCTION or NEW. Records with a 
usage flag of SAVE are ignored. 




Changing the formula used and formula itself 

When the formula associated in with a stnfam/Eq Type is changed in the StnFam 
Definition or the actual formula is changed in the TACT Formula Definition window, you 
must go to the TACT^)efinition window and regenerate the TACT values otherwise they will 
have no effect on the routing. The calculated values are stored in the TACTdef table and used 
during route exr/ort. 



TACT Formula Definition Window 

lis window defines the formulae for the TACT calculations. It is referenced by the 
Stn Definition window and used to calculate times for all stations in that stnfam. It displays 
one piaster record at a time, so acts a type 3 window. 

10 
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Each TACT formula definition contains expressions for the following fields: 



03 

m 

h 



Si 




Process time 
Setup time 
Unsetup time 
Lap time 



The formulae are used to modify the DW witt/the PowerBuilder ModifyO function 
and must follow the DW expression syntax. You /an use any expression or formula that can 
be placed in ii computed field in a DW. Do no/ use single quotes ('), use double quotes or 

10 tilde(-) instead. Only fields on the same row in the TACT definition table can be used. The 
actual names of these fields appear on tfie column headers of the TACT sample provided for 
verification purposes (in parentheses' where different from the formatted name). It is possible 
to call user defined functions alscr These must be PB global functions created with the PB 
Function Painter. The field names are not case sensitive. 

15 e.g. T21 +T3 - ceiling(j0) 
T21/2 + (Tl -T22) 

if (left(stnfarr{ 3)= "IPC" , Tl + T22, Tl + T23 - 0.25) 



You caTi test the formula on the sample TACT definition by clicking the verify button. 
20 You can altfer the TACT values to check that the formula performs correctly. The 

PowerBuilder Reports Manual defines the functions that can be used for reports and hence in 
the MpdifyO function. The Datawindow painter also lists them. 



langing a formula 
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The TACT must be recalculated when a formula is changed. Jose the Recalculate 
button on the window to do it. It will invoke the TACT Definition window and automatically 
'click' the Recalculate all TACT in TACT def Button. If this is done manually by pressing 
the Recalculate button directly on the TACT DefinitionyWindow, ensure that the retrieval was 
performed after the formula was saved to the database. 

Deleting a formula / 

The TACT must be re-calculatedVTJse the Recalculate all TACT in TACT def 
Button on the window to do it. / 

If a formula is deleted the stnfams/Eq Types that reference it will be wrong. This will 
be apparent on the TACTdef window when a Recalculation is attempted. The TACT 
formulae references must beyaltered manually through the Station Definition window. 

Verify Button / 

This applies/the current formula to the values in the Test Data window. The values in 
the test window cmn be changed to perform tests but are not saved. 

Recalculat/all TACT in TACT def Button 

This button opens the TACT Definition window and automatically 'clicks' the 
ReCal/ulate button to recalculate all of the values. The result must then be saved in the 
TACCT Definition window. The window can be used as it would be when opened from the 
menu. 
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Station Definition / 

Changing the formula associated with a Stnfam/Eq Type / 

If the formula associated with a stnfam is changed or a different formula is selected, 
the TACT must be re-calculated. Go to the TACT Definition window and click the 
Recalculate button. Ensure that the retrieval was pe^rformed after the stnfam changes were 
saved to the database- 
Deleting a Stnfam/Eq Type 

The TACT records that reference this stnfam will be wrong. This should not be done 
unless a route does not reference the/stnfam either. The Delete Records button on the TACT 
Definition window will purge TACT records no longer referenced by the routes. 
Alternatively, the usage flag csm just be changed to 'SAVE' or the records deleted manually. 
If they are just left there, thdy will not cause any errors provided they are not referenced by 
the routes. / 

TACT Definition Window 

This is a 'Type I window with some added features. The records can be retrieved by 
stnfam or 'all'. ^They are sorted by stnfam and equipment program id. New rows can be 
added, copies and deleted in the normal way. 

Key fields cannot be null and empty fields are not supported in ORACLE. Because 
this is a legitimate situation in the TACTdef table, these fields are set to the literal string 
'none', Af you try to make a key field blank, the literal value 'none' will be automatically 

13 
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placed there. This also applies to the matching fields in the Route I^efinition Window and 
this happens on import also. Stnfam should never be null. 

The fields in the window grid are as follows. They areyobtained by joining TACTdef and 
stnfamdef and only the TACTdef fields can be altered in this window. 



PROD, NEW, SA^ 
(Key field) 
(Key field) 
(Key field) 
(Key field) 
(Key field)/ 
Times in floating point mins 




Useflag 
Stage 

RecipeTitle 
10 Stnfam 

EquipmentProgld 

Reticleld 

tO 

tl 

15 t21 

t22 

t23 

t24 

t25 
20 t3 

Batchqty 

Description 



These fields are/derived and cannot be altered directly on the window 



25 Formula 

Process time 
Setup time 
UnsetuT) time 
Lap 
30 Cycte 
CycleTO 
fachine 
lachineTO 



Formula associated with the stnfam. 
Calculated by Formula 
Calculated by Formula 
Calculated by Formula 
Calculated by Formula 
Sum all t 
Cycle - tO 

(Sum all t)/batchqty 
Machine - TO/batchqty 
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Recalculate Button / 

This button recalculates each TACT by applying the appropriate formula to each row 
to recalculate the ptime, setup, unsetup and lap times. This is only reguired if the Stnfam or 
TACTformula definitions are altered. When the values on a TACT record are changed on a 
row, these values are recalculated automatically. The exception is when Copy Down is used. 
In this case, the values are not automatically recalculated/and you will be warned to do it. 
The data must be saved after a recalculation because it only changes values on the local PC 
window. / 

If there are errors because a stnfam or formula cannot be found or is invalid, a row 
will be inserted into the error window that/will appear. Double-click on the error row to 
automatically move to the correspondicrfg TACT record that is in error. 



Add Records Button / 

This scans all routes in the current model and adds a TACT record for any 
step/operation that does not have a match with a record in the TACTdef table with a usage 
flag of PRODUCTION^ NEW. This make take a minute to run. The new records are 
inserted directly into/the database so a Save is not required. They are then retrieved to the 
window. They wiil have the usage flag set to NEW. 

Discard Records Button 

Tms is the opposite of Add. It scans all routes in the current model and deletes every 
TACT /ecord that does not have a match and does not have the usage flag set to SAVE. The 
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records are deleted directly from the database and a Save is not required. Tjje TACT records 
are then retrieved to the window. 

Tact Formula Def Button 

This button is a quick way to bring up the TACT J76rmula Definition window. It is 
exactly the same as clicking the menu item. 




Adding new records 

New rows can be added in the norn&l way. The record must reference a stiff which 
will then pick up the appropriate formula. The window will automatically fetch the formula 
for that stnfam and calculate the TAJCT times. Recalculation is not necessary. 

Save 

This is performed iff the normal way by the Save menu item or toolbar. 

Changing the keys xk TACTdef 

If any of trye key fields are changed, the record effectively becomes a new record and 
the above will 

TACT History Report 

fery change to the TACT Definition is recorded in a TACT history table. There is a 
report to view the history in the Reports menu. It is not model dependent. 
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History before a specified date can be purged using the function on the window. The date is 
in yy/min/dd format. / 

The Effective date column gives the time at which the change was performed. 

Kanban Design Module 

As described previously, scheduler database^O has stored therein Kanban worksheets 
used by scheduler 32 to perform simulation runs^on production model. The integrated 
scheduling system of the present invention includes a Kanban design module to create these 
Kanban worksheets. Unlike prior art Kanban systems that use manual Kanbans that require 
dedicated human resources, the Kanhan design module of the present invention creates virtual 
Kanbans what are incorporated by scheduler 32 when creating dispatch lots for manufacturing 
execution system 20 to use. / 

The Kanban design^nodule of the present invention allows a user to design a Kanban 
system per process flowyaccording to Kanban modules definition and number of cards to meet 
required fabrication output and performance. The produced Kan van worksheet is used to 
estimate suggested/steps where the Kanban stages start and end as well as the number of 
Kanban cards for the stage. The user can manually modify the start and end locations as well 
as the numbe/ of Kanbans by entering an adjustment factor. Figure 9 shows a sample 
graphical user interface screen for monitoring and modifying Kanban information. 

TTne Kanban design module of the present invention is described in detail herein with 
reference to Figure 10. 

Kanban Processing 
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The Kanban maintenance feature provides a tool to create kanban stages using 
algorithms developed by Sony. To enable AutoSched to use kan^ans, each kanban stage must 
be defined in the kanban.txt file. Each step in a route that isin a given kanban stage must 
have the kanban name placed in the kanban field in the route.txt file. In the database, these 
files are represented by the kanban def and operdef tables. This implementation produces 
kanban definitions for a device rather than a route and the kanbans are applied to all routes for 
that device on the assumption that the essential stages will be the same. The kanban stages 
are applied automatically to a route whesiit is imported from PROMIS. To facilitate this 
requirement there is an additional tabfe in the database called kanbanxref. This table stores 
the kanban stages for a device. 

The step names in the PfcOMIS routes may vary even though the structure or the route 
is not really affected. To achieve consistent kanban stages in this situation, a step is uniquely 
identified by the stage ana kanban index which are supplied by PROMIS and stored in the 
custml3 and custml2Tields in operdef The primary key in the kanbanxref table is the route, 
stage and kanban index. 




Kanban Worksheet Window 

This window aids the user in calculating kanban stages for a given device. It 
populates the kanban def and kanbanxref tables with the kanban stages generated for a device. 
20 It canyalso update all of the routes for the device with the new kanban stages. 



unite Selection 
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Select a route from the selection window. The steps of the route will be displayed 
along with the lap times calculated from the TACT Definition. IMhere is already a kanban 
definition for this device in the KanbanXref table, it will be ajiplied and the markers showing 
the stages will be displayed along with the kanban stage names and qtys. They are read from 
KanbanXref, not the kanban stages in the route, although they should be the same. It is 
possible that the kanban stages defined in the KanfcmnXref table do not match the stages and 



If this is the case, a warning message will he displayed when the start or end of a kanban stage 
cannot be located. You will then be prompted to decide whether to try to apply the rest of the 
kanbans or give up. Either way, the problem kanban will be ignored. 

The device for this route Will be displayed and whether this route is the active route 
for the device. A route that has no device ( the device is in the Partdef that references the 
route) cannot be selected because the resulting kanbans could not lx, saved because the device 
is a key field in the kanbifnxref table. 

A kanban stage cannot start on an alternative step. An alternative step must be 
included in the same kanban stage as its primary step. This is taken into account when 
automatically generating kanban stages. 

The TACT time for an alternative step must not be used in the kanban calculations 
because it will only be performed instead of its primary step. Therefore, the Target Lap Time 
is set to aero for all alternative steps. Alternative steps are highlighted in Cyan on their row. 

Master Fields 



kanban indices in the route that is selected bee 
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A change to any one of these fields (changes are accepted when the uger tabs off the 
field or clicks on some other area of the window) causes the values in tfye route datawindow 
to be recalculated. 



Setting Kanban Stages 

The kanban stages are marked by setting markers' at the right edge of the datawindow. 




Begin kanban stage Click on row 

End kanban stage Shift-click on rc 

Single step is a kanban stage Click on row tp make it a start of a stage 

Shift click or/same row to make it an end also 
Remove marker Clicking or/a row with any marker will move the marker 



Set Formulae Button 

This will recalculates the /alues in the DW. This should not normally be necessary 
because they are automatically/recalculated anyway. It is primarily there for peace of mind! 

All steps 

This will clea/ all existing markers. A kanban stage is then created for each step by 
placing markers beside them. Alternative steps are taken into account. This does not update 
the database. 



fhis will clear all existing markers. The kanban stages are then automatically 
calcu/ated based on the Interval. The system will scan down the steps and set the kanban 
stages at the points where the Cumulative Target Days column changes to the next Interval 
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increment (e.g. if the Interval is 3, the First Kanban stage will stacfat the first step and end on 
the last step that has a value of 3. The next stage will start on/the first step that has a value of 
4 etc.) Markers are placed by the steps. Alternative steps/are taken into account. This does 
not update the database. / 

Clear Button / 

This will clear all kanban markers^om the indicator column. This does not update 
the database. 

Calc Kanbans Button 

When the markers havfe been positioned either automatically, manually or both, this 
function will assign a namar to each kanban stage and calculate the kanban qty. The name and 
qty only appear on the rdw that starts the kanban stage. The user may edit the kanban names 
and change the Adjusted Qty by changing the Management Factor on the start row for the 
stage. Do not altenor add to rows that are not at the start of a kanban stage, they will have no 
effect. This does/not affect the database. 

Save Kanbans Button 

This saves the kanban stages to the database. It first deletes the records for this device 
from theflCanbanXref and KanbanDef tables. It then saves the new kanbans to these tables. 
The S«we function in the menu and the toolbar will do this also. 
/ The kanban def table records are created as follows: 
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Kanban 

Wkanbantype 

Wkanbanatt 

Wkanbanrule 

Pkanbanqty 

Wkanabanqty 

Pkanbantype 

Pkanbanatt 

Pkanbanrule 



K - <Device>,-N 
Lot 

Anumpieces (default) 
rulek - FIFO (default) 
Adjusted Kanban Qty 
1 

Lot 

blank (default) 
blank (default) 




You will be prompted to update the routes for this device. Choosing Yes is the 
equivalent of clicking the Updates Routes Mutton. 



Update Routes Button 

This will update all of the/outes for this device with the new kanban stages. It will 
update the route that is displayed first and then go through each route in tarn. The microhelp 
at the bottom of the frame slaows how may routes and which one is being processed. The 
routes are updated by be^ng read into a hidden datawindow, updated and then written back to 
the database. 

If there is a sfroblem in a route, the process will stop. However, any routes that have 
already been processed will have been updated in the database with the new kanban stages. A 
warning message will be displayed that gives the name of the route being processed and the 
kanban, stagj& and kanban index that could not be found in the route and whether it was the 
start or end of the kanban stage. The error indicates that this route does not have the same 
stage/kanban index as the route used to generate the kanbans. If the problem is not obvious 
from tr/e message, try selecting the problem route as the route to apply the kanbans against. 
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When the route is retrieved, the kanban indicators will be set and it will £e easy to see where 
the problem stage is. 



Calculations and Default Values 



Master Fields 



Name Defaiilt 
Multiplier 

Required number of wafers out /none 
Interval (days) / 1 

Standard lot size / 25 

Plan days in the month / 30 




The following display only fields are also included: 



Device 
Active Flag 

Number of Stei 
Number of Kanban Stages 



Device the route is for (from partdef) 
Indicates if this is the active/latest route (from 
partdef) 

Number of steps in the route 

Number of kanban stages, (calculated on retrieval 

and Calc Qtys) 



tage 
step 

' Equipment Prog Id 
* Lap time 

Target Lap time 

Cumulative Target Days 

Standard WIP 



PROMIS stage 

Step 

Setup 

Calculated from TACT (hrs) 
Lap Time*Multiplier/24 (days) 
Ceiling(Sum(Target Lap Time)) 
Target*Daily throughput 
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Manager Factor 
Adjusted Kanban qty 
Kanban name 



Standard WTP in lots 
Cumulative Lots 
Kanban qty 



(Daily throughput = Required wafers out/Plan days in 

month) / 

Standard WIP/Standard Lot si/c 

Running total of Standard WTP lots 

Ceiling(sum of standard WIP in the kanban stage / 

Standard lot size) / 

Input by user. Defaultg to I 

Kanban qty * Manager Factor (qty used for kanban) 
Name of the kanbarn stage, (on the first row of the 
kanban stage) / 



The Manager Factor can be set for each Kanban by the user and is defaulted to 1 . You 
may alter the Kanban stage names if desired./ 



KanbanXref Definition 




This window displays the KaribanXref table created by the Kanban WS window. It is 
included for completeness but should not normally be used because it is difficult to manually 
correlate all of the values with/the other tables. 

The selection displays a list of devices from the Kanban Xref i.e. existing Kanban 
Xrefs. The DDDW in the grid displays a list of devices from Part Def i.e. all valid devices in 
the model. This gives' you the ability to add new Kanban Xrefs if desired. 
Values in this tableAre applied to the routes when they are imported from PROMIS. 



Save As on this window works differently to other definition windows because this 
data is never explicitly sent to AutoSched. Save As will just save the currently displayed 
dataset m the format that you choose. This is similar to Save As on reports. 



SaveAs 
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Kanban Definition 

This is a standard window that manipulates the kanban table/It has not been 
customized for this project. However, it should not be used because of the complexity of 
matching the kanbans that are automatically generated by th^Kanban Worksheet window. 



Example 

The following is an example of the integrated scheduling Vystem of the present 
invention. By way of example only, a manufacturing execution system by Promis Systems 
(PROMIS) was used in conjunction with ai/autoscheduling system by AutoSimulations, Inc. 
(AUTOSCHED) connected to a publishmg/subscribing message bus architecture to 
implement the integrated system of tne present invention. 



Transaction/Processing and Schedule Display Subsystem Dataflow 
Control Interface 

The data will be/sent from PROMIS to the DB Client in two passes, approximately 
every 3 hours, ywhich will be configurable at the PROMIS side. These passes are 
called: 

Tl / Static data (equipment, devices, routes, layers, clusters.) 

T/ Status information (WIP status, equipment status, PM counts, PM 

Orders) 

The T^pass will send all the static data that has changed since the last time it was 
sent. /This will be done early enough to give the DB Client time to process it before 
the s/atus information is sent at T2. 

The schedule will be run immediately after the T2 data has been imported into the 
itabase. Any number of Tl downloads (or none) may be performed before a n 
lownload. 

Initiating PROMIS extraction 
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The regular Tl and T2 extractions will be triggered by a Cron process on ±ne VAX. 
An asynchronous extraction will be triggered by a PROMTS command nienu with 
suitable privileges required. This will do a T2 extraction which autoinatically reloads 
any Tl data required. / 

The extraction process will first check to see that the control fde that it writes at the 
end of the extraction has been deleted by the DB Client import process. If not, the 
previous data has not yet been imported and it will not be overwritten. It will then 
output flat files to the HP/ORACLE machine via the TIB/ When the transfer is 
complete, the process will write out a control file that the import process can look for. 
The DB Client import process will poll for the files indicating the completion of the T 
I or T2 run. It will then read the data files and load/nem into the buffer tables in the 
database. In Tl or T2 downloads, the DB Client reads all the files that have been sent 
for that type of download. Files may be omitted/with no problem e.g. a T2 download 
may omit the Equipment files if nothing has changed. In the first implementation, all 
the Tl files will be sent at Tl and all the T2 /lies sent at T2. 

The control file names are: 

tlcomplete_prodla.dat 
t2compIete_prodla.dat 

Debug information may be placecfin the control files but the HP Schedule DB import 
process will not look at what is m the file, only at whether the file exists. 

When the T I or T2 data has Joeen successfully imported into the database the DB 
Client will delete the con trad file. When the control file has been deleted, PROMIS is 
free to perform the next dAa, extraction. 

In the steady state, the pB Client is looking for both Tl and T2 control files. After a 
Tl import, it continues to look for both Tl and T2 control files so that another Tl 
could be performed If desired before a schedule is run. A successful T2 import always 
triggers a scheduleyrun regardless of whether there has been a Tl import since the last 
schedule run. / 

There is a tableT called Triggerstat in the database that will be updated with the times 
of the data import. This can be viewed in an on-line report screen. 

Error situations 

Tl and T2 downloads will be blocked if the control files are not deleted for any 
reason./ 

PROMIS Import Window 

There will be a window that allows the user to import the PROMIS data under manual 
o/ automatic control. 
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The automatic mode will be started by a button on the PROMfS Import screen. This 
will automatically create an instance of the Schedule Execution screen. It will then 
start to poll for the creation of the TI and T2 control files/on the host. The poll rate is 
configurable from the Setup button but cannot be less tnan 10 sees. 

When the Tl and T2 control files are detected it win perform the import process as 
described above. When a T2 import process is complete it will initiate the schedule 
run. It does this by executing functions in the Schedule Execution screen. This screen 
will retrieve the model data from the databaserand assemble it in datawindows in the 
correct format for the asd files. It will then/reate each file in a local directory on the 
PC. It then copies all of these files to the yasd directory on the Autosched host using 

ftp. / 

When the files have all been copied to the host, a schedule run request is made to the 
Queue Manager (QM). (The QM is/a demon process that runs continuously on the 
host.) This is done by creating a directory under the QM directory on the host and 
placing various control files there. The QM polls for the creation of these files and 
will then execute the schedule/The DB Client will then poll for the schedule 
completion or failure by looking for control files created by the QM. When the run 
has completed, the DB Client will import the schedule file (modelname.sch) into a 
datawindow and process i/the data will then be written to the as-schedule file with 
the new schedule name and modelname as the key. 

The Dispatch List wil/then be created in the Lotstat table. The Lotstat table which 
contains one record for each lot is then deleted and re-created from the Orderstat table 
that was used to create the new schedule. If a lot is in the waiting state the next 
step/stn fields are /et up from the new schedule. All of the transactions that happened 
since the start of/he T2 extraction will then be reapplied to Lotstat to bring it up to 
date with the current PROMIS status. 

Manual Mode / 

The PROMIS Import screen can be used in manual mode, to import each dataset 
individually and break the import sequence down into its component parts: 

a) f/p files from HP to PC 

b) Read data into database buffer tables 

c) /Process data in the buffer tables and populate the definition tables 
Theyuser can also enable audits in the import functions where they exist. 

Import Setup 

The Ftp name, login and password for the PROMIS data import may be different to 
Ahat of the scheduler. The scheduler may be run on the same host under a different 
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login or on a different host. The scheduler parameters are setup via the Host 
Definition and Model Properties screens. There will be a setup button on this screen 
that allows the user to specify these parameters and also the. Tl and T2 directory paths 
and the poll rates. The values will be stored in a file cajfed Import.ini on the PC. 

Data Interface / 

The following datasets will come from PROMIS at time Tl and T2. In general, Tl 
data will only be sent if there has been a change since the last time it was imported 
into the database. Tl data may also be resent at T2 if there is a change between Tl 
and T2. The T2 data will be importedyiri its entirety at T2 regardless of what has 
changed. 

Data sent at time Tl 

Station Families 
Stations 
Clusters 

Parts / 
Layers / 
Routes / 

Data sent at time T2 / 
Lots/WIP Statds 
Station Statyfe 
PM Counts/and Limits 
PM OrdeFS 

Locking and Concurrency 

The data frorn PROMIS will be written into buffer tables, not directly into the 
Schedule wB tables. The reasons for this are: 

a) The number of fields that the PROMIS import fills in for a given record is 
/small in relation to the total number of fields. A buffer table eliminates the 

/ need for the interface to know what all the fields and their defaults are. 

b) / Buffer tables isolate the PROMIS interface code from changes to the Schedule 
/ DB. 

c) / Buffer tables simplify locking and Concurrency. 

dp Buffer tables allow additional checks and processing to be easily added 
/ because they will processed by PowerBuilder functions. 

/ When buffer tables are being populated, only the import interface will be using them. 
/ When the import of that dataset is complete, the import process will update the trigger 
/ flag in the Trigger table and will execute a PB function to update the target database 
/ tables. 
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Due to performance considerations, the Route import is uses a different procedure. 
The Tl file is imported into a datawindow and then the datawindow is passed the 
route import function which processes it directly and writes the/lata to the route and 
operdef tables. This reduces the processing time by omittingiiie buffer write which is 
insignificant for the other tables. / 

When the DB procedure updates a target database table/from the buffer tables, the 
following procedures will be followed: / 1*^ 



Optimistic locking is used throughout the system/ When a record is updated, a field 
called update val is incremented. This field is utfed as a key in the SQL WHERE 
clause, so that if another user alters the record'and writes it back, the user's update will 
fail because it will not be able to find the record it is updating. Where there are 
multiple records in a dataset (e.g. Routede/, operdef, operoperatorxref, opertoolxref), 
the updateval in the "master" record is always updated if any detail record is updated, 
added or deleted. So any change is a change to the whole Route. 

When a change is saved, all tables involved are write-locked briefly. The updating 
process will wait on a write lock request until it is granted which will be in a few 
moments if all other processes are following the strategy. To avoid deadlocks, the 
correct locking order of tables/in a Multi-State Transaction (MST) must be followed. 

If a user is updating a table/at the time the DB procedure runs to populate the DB 
Client, the following resujis may occur. A user should only be updating certain 
default fields in the dynamic tables. Changes to datasets such as WIP will be lost 
every time the import puns. Changes to datasets such as Routing will be lost every 
time they are reloaded!. 

a) User has table open for edit and the DB procedure starts and completes before 
he saves ms changes. Any changes to records that the DB procedure has 
updated/will be lost because he will not be able to save them. He will get a 
suitable warning when he selects Save. 

b) User tries to save his changes before the DB procedure changes the records he 
is>working on. His change will work but may be overwritten by the import 
process. He will not get a warning. If the record existed for him to update it 
An the first place, the DB procedure will probably only have performed an 

/ update on the dynamic fields and he should only be changing the static and 
/ lookup fields, so his changes will not be lost. He should not be changing 
/ dynamically updated fields. 

M screen will be provided in the utilities menu to allow the user to view the Trigger 
/able. This will provide an idea of when the last import occurred and whether one is 
progress. 
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When a dataset has been loaded into the buffer table, the import m^cess will update 
the appropriate record in the Trigger table by setting its trigger frag to "Y". 



A detailed d e finition of each buffer tabic appeal & in tlRy ' dppentfo ^ 



Comments 

Y when import complete 
Information only, time when flag was set 
Information only, time when post-processing completes 
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Triggerstat 

Field 

Dataset 

Triggerflag 

Triggertime 

PPCompletetime 

Valid Dataset names are 



STN 

STNFAM 

CLUSTER 

PART 

LAYER 

ROUTE 

WIP 

STNSTAT 
PMCOUNT 
PMORDER 
Tl COMPLETE 
T2COMPLETE 



Buffer Table lpile Names 

The T1/T2 fjfe names will be of the form: 
1 a_<dataset namo.dat. 

dataset_name is in lower case. 

TableAlaintenance 

The/imported data will create or modify records in various tables. In many cases, it is 
nej/ther possible nor desirable to automatically delete records from tables just because 
model does not appear to use them. In these cases, the data must be managed 
lanually. See below for a details of where this applies. 

Log File 

A log file will be kept on the PC to record major events and errors. 
Action on Import 
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When a dataset is imported from a PROMIS file, the data may be used to irpdate 
existing data or it may completely replace the dataset. The following ta^le 
summarizes this. / 

Delete all the existing data is deleted from the production inodel and replaced 

with the new data / 

Insert records received from PROMIS that do not currently exist in the 

production model are added to the database / 

Update if the record received from PROMIS currendy exists in the database ft 

will be updated with the data from PRODIS . 

Data sent at time Tl 

Stnfam/Equipment Type 
Stn/Equipment Id 
Clusters 
Parts 
Layers 
Routes* 

Data sent at time T2 

LotsAVIP Status 
Station Status 
PM Counts and Limits 
PM Orders 

* Routes are treated as an entity. When a route is received from PROMIS, the import 
process will delete the route/and all of the steps if the route already exists and then 
replace it with the new on&. New routes will be added, routes that do not have a 
replacement will not be deleted. 

Tl Data Import / 

Stations/Equipment / 

The informationahat comes from PROMIS at Tl will be mapped to two buffer tables 
as follows. S ec the appe n dix for a detailed definition of the table s^ 

StnBuffer / 

Field Comment 

BquipmentType stnfam 

Equipmentld stn 

StnfamBuffer 
/ Field 
/ EquipmentType 
/ PROMISlocation 




Insert, update 
Insert, update 
Delete 

Insert, update 
Delete 
Insert, updai 



Delete 

insert/update 
Delete 
Delete 



Comment 
stnfam 

PROMIS location (Area) 
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PMRulel 

PMRule2 

PMRule3 



PMRulel 
PMRule2 
PMRule3 
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Details of Mapping 

This information populates two tables in the Schedule DjB, stnfamdef and stndef . 
When this data is received, existing records will be updated or new ones added. 



Stndef 



If stnfam is changed, it must be in the stjrfamdef table. A new record will be 
inserted if not there. 

If there is a new stn, a record will be/added plus a record for stnfamdef if it 
does not exist. 

No existing records will be deleted. Records are added or modified. 



referei 



Stnfamdef 

There must be a record foc'each stnfam referenced by the stndef table. It is 
valid to have an stnfam \vithout any stns, as could happen in manual input. 
No existing records wirf be deleted. Records are added or modified. 

No audit capability will be/provided. The tables can be manipulated using the 
standard screens where deleting a stnfam deletes all the associated stns. The 
additional Sony fileds fields below must be populated manually. 

Additional fields 

There will be a field that will provide the default value for ptper in each step record in 
a route that uses this stnfam. This will be mapped to a custom field in stnfamdef 
There is also>a field that references the TACT formula to be used to calculate Ptime 
etc. for step/ using the stnfam. The PMRules will also be stored in stnfamdef 



Stnfamc 



Ptper 

TactFormula 
PMRulel 
PMRule2 
PMRule3 



Description 
Ptper 

Formula for TACT 
PM Rulel 
PM Rule2 
PM Rule3 



Default 
"Lot" 

CONSTANT 
empty 
empty 
empty 
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The information that comes from PROMIS at Tl will be mapped to a buffer table as 
follows. Sec the appendix f or a de t ailed definition of tho tablo^ I f there are any 
changes to this table the entire table will be downloaded from PROMIS at Tl. 
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ClusterBuffer 
Cluster 
Equipmentld 
ActiveFIag (Y/N) 

Details of Mapping 

In the AS model, all steppers are grouped into a single stnfam. The cluster table 
groups them in a different way and custom AS code uses this table to decide what 
stepper to use for a lot and step. If a lot starts jout using a stepper in clusterN, it must 
always use a stepper clusterN for all of its sjepper operations. It is therefore an 
attribute of the lot. 



All existing records will be deleted at|ne s^j^ofljie import process. 
Parts/Devices 

The information that comes fro/6 PROMIS at Tl will be mapped to a buffer table. 




PartBuffer 
Field 
Partld 
Device 
Procedureld 
Process 

custm9 

Details of Mapping 



Comment 

Partname in partdef 

Mapped to a custom field in Partdef (custml 1) 
Routename in partdef 

PROMIS Process name for the device (custmlO) 
0 initially, manually maintained (custml 2) 
Y/N the active route for this device (custm9) 



The Part definition is essential in AS because a lot makes a part which references a 
route. Thefre is no direct link between lot and route. This is an issue because there 
could be /wo lots making the same device that are using different routes. The solution 
is to map the AS Part to the PROMIS Part id and add an extra device field to the 
Partde/ table to store the device. The device name will be a concatenation of the Part 
ID and Primary Procedure ID. There is an explicit field for the Primary Procedure ID 
whi/h is the AS route for this part. 



5 art id 
Device 
Procedure Id 
Process 
ActiveFIag 



AS 

Partname 
Custml 1 
Routename 
CustmlO 
Custm9 



K-1053.02_K-1053.9 

K-1053 

K-1053.9 

YorN 
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Manually updated fields 



10 



Field 
dfltld 
dfltldu 
Custm 12 



Custm 13 
Custm 14 
Custm 15 



Default 
0 

sees 



Comment 

default lead time fields 
units 

pgd for Common DB. Will be downloaded from 
PROMIS but \jtffl be 0 initially so must be 
manually upda 
fin Good 1 for Common DB 
chip Size J^for Common DB 
chip Size W for Common DB 



15 

□ 
ffl 

P 

m 20 

w 

ru 

s 

5 25 
u 



The part record must be edited by hand tc/add the default load fields. If the part 
record does not exist in the table a reco/a will be created with defaults for the default 
load values. 



No existing records will be delet^ 
provided. 



Records are added or modified. No audit will be 



Layers 



SI 
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The information that corries from PROMIS at Tl will be mapped to a buffer table as 
follows. £ec-t he a ppend i x for a detailed defin i tion of theis tble^ If there are any 
changes to this table me entire table will be downloaded from PROMIS at Tl. 



LayerBuffer 
Field 



ame 



Locati 
Laye 
Equ/pmentld 
tiveFlag 
rocess 



Comment 

(not passed through to AS) 
Key field 

I/A/M 
Key field 
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Details of Mapping 

Trje layer name is related to a stage in the routing in which there is a stepper step. The 

/er table indicates which steppers can be used to perform a given layer in a given 
route. Therefore, when a stepper stn is looking for a lot to process, the lot must be for 
the same cluster as this stepper and the layer to be performed must be valid for this 
stepper to do. 

All existing records will be deleted at the start of the import process. 



loutes 
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The routing information adds records to the Routedef and Operdef tables. There is 
one record per route in Routedef. There is one record per sten/m Operdef. The 
Routedef and Operdef records will be created from the PRQMIS data plus a number 
of lookup tables. 

There will be a flag in PROMIS that will allow the us^r to say which Routes should 
not be included in the extraction. This will allow the user to stop the extraction of 
engineering and test routes which may change oft^n r^uTwhich are not needed for 
scheduling. 



RouteBuffer (one record per 
Field 
Route 
Step 

EquipmentProgld 

Reticleld 

RecipeTitle 

Stageld 

Alt 

ASSpecProc 
Recipeld 
EquipmentType 
StageLocationld 
Subset 
Fab 

Kanbanlnde? 



PMrulelirg 1 
PMrule/arg 2 
PMrufelarg 3 
PMn4le2arg 1 
PMrule2arg 2 
P^rule2arg 3 
lrule3arg 1 
5 Mrule3arg 2 
PMrule3arg 3 



step) 

Comment 

primary procedure id 
unique name generated by PROMIS 
setup 

e.g. £>XIDATION, PRETREAT 
stage 

'= Alternative step (N or empty otherwise) 
f=special processing e.g. Wet Stn, N otherwise 

stnfam 

process location (set) 
PROMIS stage + device 
superset 

When combined with Stage, this provides a unique 
index to a step but will be more static than the step 
name. 

Arguments for PM rules 



Node: Step names must be unique within a route including the names of 
alternative steps. The combination of Stage and Kanban Index must be unique 
ithin a route. 



(Details of Mapping 

When a route is received from PROMIS, the existing route of the same name will be 
deleted. This includes the Routedef record and all associated Operdef records. For 
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completeness, the records in other tables associated with a route will be deleted, 
though they will have no entries in the Sony model. They are Operoperatorxref and 
Opertoolxref that define operators and tools required for arstep. The new route 
records will then be inserted. No routes will be deleteayfn this interface except for 
ones that are being replaced. No audit will be provide 

When the routes are exported to the scheduler, some other fields are modified 
automatically based on values in the TACTdef table and other values in the routing. 
This ensures that TACT changes are picked un/as on the next schedule run regardless 
of whether there is a Tl import. 

PROMIS will generate a field called AS^pecproc that is a string to indicate that the 
import code has to do some special actions on the step. The only one identified so far 
is Y to indicate a Wet station step. The fields in the Operdef records are generated by 
the PB function as follows. Any fiela not listed will be given a default of blank/null. 



PROMIS 

primary procedure 
unique name generated by PROMIS 
stage 

equipment type 



equipment prog id 
recipe title 



asspecproc 
combine 

stage location id 
fabname 

PROMISy&tage+PROMIS device 
recipe k 
reticle 



DB Client Comments, examples 
routename 
opername 
custml3 
stnfam 
ptper 




setup 
when 
operdesc 
agenda 



combname 
set 

superset 
subset 
custm 14 
custm 15 
rework 



rwkrtepart 
rwktype 
rwkstep 
rejoin 
stnexec 1 



depends on equipment 
type copied from stnfamdef table 
required setup for this step 
Defaults to "Need" 
e.g. OXIDATION, PRETREAT 
from lookup table 
RouteParamDef 
Y or N (not copied to operdef) 
from lookup table 
RouteParamDef 
process location 
FablA 



Rework is defined for Wet 

stations only. 100% the whole lot 

goes to rework 

'R'+stnfam+equip prog id 

Lot 

1 

Next step in the route 
from lookup table 
RouteParamDef 
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stnexec2 


from lookup table 
RouteTaramDef 




stnexec3 


from lookup table 
RouteParamDef 




stnexec4 


/from lookup table 
RouteParamDef 




stnexecS/ 


from lookup table 
RouteParamDef 


— 


stnexeco 


from lookup table 
KouteParamJJet 




Daicncnrt 


from lookup table 
KouteraramUer 




/batchmn 


from lookup table 
Kou teParamUet 




/ batchmx 


from lookup table 
Kou teParamDer 




/ kanban 


from lookup table KanbanXref 


PM rule 1 , arg 1 


/ custm 1 7 


Arg 1 for rule 1 


PM rule 1 , arg 2 


/ custm lo 


Argz tor rule 1 


PM rule 1, arg 3 


^V— custm 19 


Arg3 for rule 1 


PM rule 2, arg 1 / 


custm20 




PM rule 2, arg 2 / 


\ custm21 




PM rule 2, arg 3 / 


V custm22 




PM rule 3, arg 1 / 


custm23 




PM rule 3, arg 2 / 


custm24 




PM rule 3, arg 3 / 


custm25 




Kanbanlndex / 


custm 12 


Kanban index 



Note: ptper, ptime, setup time and unsetup time are set during the export of the data 
to AutoSchedJ 

Rework and Split Steps 

The simulation will never split a lot or move a lot or split to a rework route on a 
statistical basis except where reworks have been used to model "normal" flow. e.g. 
WET stations. The lot status from PROMIS will include splits and lots in rework. 
This i/formation has to be added to the internal Lot load record in AS and need not 
appear in the route. The only information pertaining to these situations that has to be 
in ttfe route is the points at which Lots combine after being split. These points are 
defined in the Routeparamdef tables with the combinename field. The combinename 
is/not really necessary as one will be created and added automatically by the WIP 
imprt if needed. 

Wet Stations 

Where a WET station is modeled by a rework route, the rework fields will be filled in 
as follows: 
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Rework 

Rwktype 

Rwkstep 

RwkRtePart 

Rejoin 



100 
Lot 
1 

R+stnfam+Equipment Program 
Next step that is not an alternative step (cannot rtum to an alt 
setp) 




Test Stations 



For test stations, identified by stnfam = 1 POTEST, the lot may be all or partially 
retested. The rework route will rejoin at tne same step and the combine with the 
Parent lot (if any) there also. i.e. if test is at step 10, rework route is on step 10, rejoin 
is step 10 and combine is step 10. Th? combine name must be placed in the routing. 
Rejoin is not required as it will be aylot attribute. 



There will be no rework steps 
They will be maintained by haj; 
in the routing. 



I in the routing between PROMIS and DB Client, 
in the DB Client DB. There will be alternative steps 



There will be a lookup table called Routeparamdef to populate fields in operdef. 



Routeparamdef 



Field 
stnfam 
recipe id 
equipmentPr 
batchcritf 
batchmn 
batchmx 
stnexec ] 



>Id 



Keys 

Primary Key 
Primary Key 
Primary Key 



equipment type 
setup 

batching fields 



stn exceptions. Stops defined equipment 
ids from being used for the step 



stnexe 
stnexec3 
cxec4 

stp 

iexec6 
bombine 
agenda 



required if splits rejoin at this step 

in case agendas are needed in the future 



This table will not be updated automatically by the PROMIS interface. It will be 
maintained manually. 



lariban Insertion 
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The kanban rules are critical to the scheduling of the Fab. Kanhan will be performed 
by step and every step in a Kanban stage has to have the nanWof that Kanban. The 
Kanban information will be added to the route when it is imported. The information 
will be in a new Kanban cross reference table called KanbanXref. The user will 
define the device, the begin and end stage of each kanj*an and specify the Kanban 
name via the Kanban Worksheet. 



The kanban name will be written to each step in4he route starting at the first step in 
the specified start stage and ending at the last^step in the specified end stage. This will 
be done in the DB procedure during the import of the routes or from the KanbanXref 
screen when a change is made to the KanbfanXref table. Alternative steps cannot start 
a Kanban stage and must be included in/the same kanban stage as the primary step. 



KanbanXref 

Field 
Device 
BeginStage 
Beginlndex 
EndStage 
Endlndex 
Kanban 
Seqval 

ManagemertfFactor 




'rimary Key 
'Primary Key 
Primary Key 



Foreign Key 



Comments 



Part without the version suffix 

Stagename in operdef 

Identifies the step within the stage 

Stagename in operdef 

Identifies the step within the stage 

Refers to standard AS Kanbandef table. 

Sort order field 

The factor set by the user. Note that this 
is only saved for each kanban stage, not 
for each step. 

The kanban qty written to the kanbandef 
record for this stage 



Note: It will not be possible to have two different kanbans starting and ending at 
the same pages even though the groups referenced may be in different sections of 
the route. 



The^CanbanXref table will be maintained through the Kanban Worksheet screen that 
will populate the Kanbandef and KanbanXref tables and apply the Kanbans to the 
steps in the routes. When a new route is imported, the system will apply the kanban 
tages as best it can from, the KanbanXref table. The assumption is that route changes 
/ill be minor with respect to changes in stages and steps that affect kanban. It will be 
'up to the user to check the resulting AS route whenever there is a change. The 
combination of stage and kanban index is used instead of the step name. This is 
because the step names are rather fluid even though a change to a route might be 
minor. 



T2 Data Import 
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Station/Equipment Status 

The information that comes from PROMIS at T2 will be mappe'd to a buffer table as 
follows. The trigger can be set when the table has been loadea. 



StnStatBuffer 
Field 

EquipmentType 

Equipmentld 

Down 

Dwunttime 

Cursetup 

Details of Mapping 



Comment 

stnfam 

stn 

See table below 
See table below 
See table belo\ 




The Status of each equipment id will 
status of the station and its current sejt 
whose meaning is described below 



downloaded at 72. The data provides the 
lp. The status is placed in the Down field 



The Down field combinations are as follows: 



Equipment 
Status 



Down 



)wunt 



Dwunttime Units Cursetup 



up, active 0 
UP, idle 0 
DOWN 1 
Running PM 3 

When DOWN=3, 
"11/27/95 12:03:( 



Equip_prog_id 



DateTime 



iwunttime is the date/time at which the station will be back up. e.g. 



There should newer be a situation where an equipment id is imported at T2 for which 
there has not been a record imported at Tl . There will be an audit to check for and 
repair this is Math a default record in stndef and stnfamdef if required but will not 
normally be'enabled. The station will be defaulted to UP with no cur-rent setup. 



Lots (WJP) 



The information that comes from PROMIS at T2 will be mapped to a buffer table as 
follows. -See-the appendix fo r a detailed definit io n of the tabl c^ The trigger can be set 
when/the table has been loaded. 



^StatusBuffer 
OrderName 
Lodd 



Tilde character if lot is in storage Note 1 
Lot id 
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LotType 

PartID 

Qty 

Starttime 

Duetime 

AsSpeccProc 

LotStatus 

Currents tep 

CurrentStage 

CurrentEquipId 

CurrentEquipType 

Recipeld 
EquipmentProgld 
TrackinTime 
Priority 
SplitFlag 
ReworkFlag 
ParentLotld 
CombineStep 
ClusterPhoto 
Cluster2 
Cluster3 
Cluster4 



Lot type (2 chars) 
Device + Rev concatenated with/Primary Procedure ID 
Qty of wafers in lot 

Actual start if lot is WIP or scheduled start otherwise 
NULL 

Y or N (e.g. Y for Wet Ration) 
0-Normal, 1-Hold 
Current step or emn# if not started 
Current stage or einpty 
Current equipment id or empty 

Current equippfient type or empty (also empty if lot is on 
hold) 

Current rec/pe id or empty 
Not used/out may be needed later 




*or future temporary split processing 
^Cluster names assigned to Lot 



Note, the first line of the file will contain a single datetime in the first column that 
gives the time of the/start of the WIP T2 extraction. This will be the simulation 
start time. 

The WIP file fropn PROMIS will generate the Orders for AS via the Orderstat table in 
ORACLE. The/WIP file will be put into a buffer DB table and then a function will 
run to process It into the Orderstat table. The main issue is dealing with lots that are 
currently spli/ or being reworked. 

Details of Mapping 

The Ordefrstat file will be completely deleted by the DB procedure. It will be 
recreates using the following data: 



String created by PROMIS 
fronv the scheduled start date. 
Should not have characters like 
colon or slash. 
*Id 
3tType 



AS 

Ordername 



Lotname 
Type 



Comments 

If this is the tilde, the lot is in 
storage. The schedlevel field 
will be set to 10 to stop it being 
scheduled. 
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Partld 

Qty of wafers in the lot 
If Lot is in WIP, then actual 
start date/time. Otherwise, 
scheduled start date/time 
NULL 

Interface should extract the 
current value from PROMIS for 
possible future use 

Lot Status 



Current step or empty 

Current equipment id 

Equip prog id 

Current equipment type 

Current stage 

Track-in time for this step 



Priority 



Partname 

Pieces 

Starttime 



Duetime 



Trace 
Hold 

Hldupfttime 
Hldrfnt 
Juunu 
^urstep 
r Curstn 
Custm9 
Custm 10 
Custm 1 1 
Stpst 
Rem 
Action 
Prior 




0=Normal 
l=Hold 
NULL 
0 

mins 



100% (default) 
1 

Lot Priority 



Clusterphoto 
Cluster2-5 



Custm 1 
Custm2-4 



Photo Cluster 
Future Clusters 



The determination/as to whether the lot is in rework or a split will be determined as in 
the following table. 



Type 



flag 



Current 


Current 


Recipe 


Parent 


Equip 


step 


stage 


id 


lot 


ment 










type 


Current step Current 


recipe id 


empty 


Equip 


in route 


stage lot of 


(n/a) 


Type 


(empty if not 


is on 


current 






started) 




step 






Current step 


Current 


recipe id 


empty 


Equip 


in route 


stage lot 


of 


(n/a) 


Type 




is on 


current 










step 






Current step 


Current 


recipe id 


Parent 


Equip 


in route 


stage lot 


of 


lot 


Type 



Single Lotf N 
Permanent 
Split 



Lot t/n N 
rework 



Split Lot on Y 
' rework 



N 
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Temporary Y 
Split 



is on 

N Current step Current 
in route stage lot 
is on 



current 
step/ 
recipe id Parent 
/5f lot 
current step 



Equip 
Type 



The way PROMIS defines a rework route is differenj/k> the way in which it is defined 
in AS. In fact, the lot performs a few extra steps a#a then repeats the steps in the 
route immediately before the rework. In PROMJS, the whole set of steps that the lot 
goes through is defined in the rework whereasyin AS, only the extra steps are defined 
with the lot rejoining the route at a point where it can repeat some steps. Therefore, 
when a lot is in rework in PROMIS, it mayactually be in the rework route in AS or 
repeating steps in the normal route. 

e.g. 




PROMIS 
Standard 
Expose 
Inspect 



Rework 



Strip 
Clean 
Expose y 
Inspec 



Sem 
Etch 



AS 

StandardRework 

Expose 

Inspect 

Strip 

Clean 

(rejoin route at Expose) 

Sem 
Etch 



There are two dases: 



a) the kit is on the PROMIS rework route on a step that is in the AS rework route. 

b) the/lot is on a PROMIS rework route but is really re-doing some steps. This is 
gapped to the original route in AS. 

The recipe id of a step on a rework route that is really a duplicate of the original route 
ause it is being redone) will be the same as the original step 

Fvfid the corresponding step in the AS route 

nnd the recipe id in the standard route 
If the step is found, the lot is on the standard AS route 

Current step is the step found 

Set Rejoin, RwkRtePart fields to blank in lot load 
Else (the lot must be on an AS rework route, see if its RPRPBM) 

Look for step with same stnfam in the rework route RPRPBM (photo before 

metal) 
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Current step in the AS rework route is the one whose stnfam nrfatches the 
current equipment type Set NsRtePart = PRPBM / 
Set curstep equal to this step / 

Else (the lot must be on an AS rework route, see if its RPRPAM) 

Look for step with same stnfam in the rework route FfPRPAM (photo after 

metal) / 

Current step in the AS rework route is the one whose stnfam matches the 

current equipment type Set NsRtePart = PRPAM 

Set curstep equal to this step / 

End if / 

If on a rework route / 

Find the step to which the lot should return in the standard routing 

i.e. Find the step in standard routing with staseliame = layename.PR reticle id = 

blank / jlf^) 

Set Rentry equal to this step / f J 

alto alt / 1 N — ' 

End if /V 

Set the split fields in the load for this lot if it was split for rework 

If the lot is a split / 

Find the step at which the parent lot is waiting. This is the combine step. 
Read the combirie name from this step. The splitname must be set to the 
combine name/ror it to join the parent lot. If there is no combinename (which 
is inserted fr^m RouteParamDef), one will be created and the route updated. 
Add the splitname to the lot load* 
Add the s|flit lot id to the parent lot linked list* 

End if / 

* This is performed by a User Exit in AS. The DB Client DB sets the splitname, 
combinename and parent lot in custom fields in the operstat (lot) record. 

Note: Because rework steps are explicit for each place in PROMIS but are more 
generic in AS, the resulting names may be different. 

Temporary Splits that are not Rework 

Arbitrary temporary splits will not be handled. 

Test Stations 

At test stations, identified by equipment type/stnfam = 1PCTEST, the lot may be all or 
partially retested. The rework route will rejoin at the same step and the split combine 
is there also. i.e. if test is at step 10, rework route is on step 10, rejoin is step 10 and 
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combine is step 10. The combine name will already be in the route.yif the lot is in 
rework, the rework flag will be set. 

The logic for this situation is: 

If current station type = 1 PCTEST and in rework 
Find the rejoin step 
set lot rejoin = rejoin step 
If lot is a split 

Find the step at which the parenj/lot is waiting. This is the combine 
step 

Read the combine name from'this step and place in lot split attribute 
Add the split lot id to the parent lot linked list 

End if 

Else 

Normal Lot processing 

End if 

Wet Stations 

At Wet Stations, the lot will/be placed on the Wet Station rework route. This is 
identified by first checkinsrthe Asspecproc in the WIP. The rentry attribute of the Lot 
will be set to the current /tep. The lot will be placed at the start of the Wet station 
process because there \j currently no way to determine where in the Wet Station 
sequence a lot is. The* parameters will be set as follows: 

Nonstd = yps 

NsRtePaiy= R+stnfam+Equipment Program id 
Rentry ^Current step 

Curste 
Cur&fo 
stpst = 

Abortedr Track-ins 

Aborted Track-ins will not cause duplicate entries in the Order table. This currently 
happens when a certain report is run to feed the offline scheduler. 

Alternative Steps 

The mapping of alternative steps will be handled in PROMIS and be transparent to the 
/Schedule DB. The logic that PROMIS will use is as follows: 

e.g. 1000 Normal step 

1000.A1 Alternative step 
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If lot is in process and in the Alternative Step 

current step = 1000.A1 
Else (lot in wait) 

current step = I 000 

Endif 



PM Orders 





The PM Orders specify the PM operations that are 
equipment (stn). 



PMOrderBuffer 
Field 
PMOrder 
EquipmentID 
Duetime 
Ptime 
Winmin 
Wimmax 
Interval 
Frequency 
DayofWeek 
WeekofMonth 
MonthofY ear 

Details of Mapping 

The mapping is as foflows: 



e scheduled for a piece of 




Comment 
Name of PM 

Equipment PM is to be performed on 
date/time when PM will start 
time PM is expected to take (floating point mins) 
Float 
Float 

Floating point mins 
Characteristic (weekly, monthly, etc.) 
fteger 
iteger 
Integer 



PRQMIS 
Task ID 
Equipment 
Duedate 
Ptime 



DB Client 

PMOrder 

Stn 

duedate 

Ptime 

Ptunits 



Comment 



mins 



Theseyfields are copied into the database by are not used by AS at present: 



Winmin 
^in max 
fnterval 
' Frequency 
DayofWeek 
WeekofMonth 
MonthofYear 



Custm2 

Custm3 

Custm4 

Custm5 

d2 

d3 

d2 
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All existing PM Orders are deleted. 



PM Counters 



10 

CA. 



In addition to the standard PM supported by AS, thafe are some additional 
requirements based on various rules peculiar to the equipment used. These will be 
handled by some additional fields in the data imported from PROMIS. 

The information that comes from PROMIS At T2 will be mapped to a buffer table as 
follows. See tho appendix f u i a de t ailed " iffiinition of th e table ^The trigger can be set 
when the table has been loaded. 



15 



20 



25 



PMCountBuffer 
Field 



EquipmentID 

TaskID 

Limit 

Winmin 

Winmax 

Arg 

PMDuration 

CounterType, 

CounterValue 




Float 
Float 
Integer 

Time required to do the PM (floating pt mins) 
e.g. RF units 

Current value of PM counter 



PROMIS will add some additional fields to the end of the station and route records. 
These are defined in the sections on importing Routes and Stnfams. 



Stnfam 
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Stn/am Rulel Rule2 Rule3 
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Route 



Step (Rule 1) Arg I Arg2 Arg3 
Arg2 Arg3 



(Rule2) Arg I Arg2 Arg3 (Rule3) Arg I 



This says that for a given equipment type up to 3 rules can be applied. The parameters 
used in these rules depend on the step that is being performed. 

le rules accumulate counters for the stn (equipment id) which are then checked 
r against the PM limit table for that equipment id. AS should not start a step if the PM 
limit will be exceeded during that step given the Window. 

The rule will calculate the value for the step based on the lot etc. and then add the 
result to the appropriate PM load. It will be hard coded to know which type of load it 
is looking for using counter type. 
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When a PM happens, the equipment will be out of service for PM fo/ duration hours. 
Details of Mapping 

Each record in the PM Count Buffer will create a record set (a'PM and MTTR row) in 
the Calendar file and a record in the Calendar Attachment fife. All existing PM 
records will be deleted from the Calendar file and all PM .records will be deleted from 
the Attachment file. 

PM Counter table 




PRQMIS 



DB Client 



Equipment id Attach. Resname 

Task Cal.Calname 

Attach. Cain ame 
counter type Cal.Ref 



current value Cal.Custml 
limit Cal.Argl 



Winmin 

Winmax 

Duration 
Arg 



Custm2 

Cal.Custr 

Calmtti/Argl 
Cal.Crfstm4 

Attach.Restype 
tach.Caltype 
Utach.FOA 



Comments ^examples 
Equipmen/that PM is for. 

The name of the PM load to pull this stn out of 
serviae identifier that 

the llser can understand in relation to this PM. 

lat the rule is looking for. Sets the 
folendar.ref field as follows: 
>t=mttf_by_lot 
Wafer=mttf_by_pieces 
xxxx=mttf_by_xxxx 

How many units accumulated since last PM. 
Limit for counter value within window. 
Calendar, argl 

Window in which PM must be performed (in 
units). 

Window in which PM must be performed (in 
units) 

MTTPM (floating pt mins) 

Chamber number 1-3. Anything else is 

interpreted as 1 . 

Stn 

PM 

blank 



StnDef 

On exportyto AS, the fields in stnfam will be copied to the stns in their family in the 
stn.txt fil/. They are not copied to these fields within the database. 



Stnfamdef 
PMRulel 
PMRule2 
PMRule3 



StnDef 
Custml3 
Custml4 
Custml5 
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If the simulation decides that a PM is due, it will create a PM Order that will show up 
on the dispatch list for that equipment id. 

Creating the Schedule 

Data Export to AutoSched (.asd files) 

Most of the files are created directly from the defrnition tables in the database which 
are created by the PROMIS import and/or manually as described above, there are the 
following exceptions: 

The Route file is joined with the TACTdef table to create the various step times. Each 
operdef/step record will be joined with i6 TACT record as follows: 



Operdef 

Stag 
Stnfam 

EquipmentProgld 

Reticleld 

Useflag 



TACTdef 

Stage 
Stnfam 

^entProgld 
Reticleld 

PRODUCTION or NEW 




The following fields arer setup in the route file based on this join: 

Ptime tactdef.ptime 

CustmlO tactdef.stime 

Custm 1 1 tacraef.unsetuptime 

xpiece IF operdef.ptper ='xpiece' THEN tactdef.batchqty ELSE 0 

setup JF operdef. setup ='none- THEN" ELSE operdef. setup ENDIF 

The simulation start time in the Option s.def file is set to the T2 extraction time that 
was passed/in the first line of the WIPstatus file. 

The schedule name is generated at the time of the run and is related to when the 
schedule is run, not the T2 time. It is geneated as follows: 

Fabla<mmdd>-<hhmm> 



Create Dispatch List 



\X T2 a new WIP dataset will be extracted from PROMIS while the current schedule 
^and status is being used by the Fab. There are a number of sequencing problems that 
will be handled as described here. 

In the "steady state", the lot status will be in the Lotstat table, one row per lot and the 
schedule will be in the as-schedule table keyed by model name (PRODUCTION) and 
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the name of the schedule. At T2, the WIP status is placed into the Ofclerstat table and 
then passed to AutoSched. Meanwhile, the Lotstat table is the table being used for the 
schedule display. When the schedule is complete, it will be placed into the as- 
schedule table under a new name and the Lotstat table will/be overwritten with the 
Orders from Orderstat from which the schedule was created The oldest schedule will 
be deleted. / 

The process joins Orderstat and as - schedule and ^opies it to Lotstat. The current 
step, stn from Orderstat are copied to the current artep fields in Lotstat. The step, stn 
information from the first step for that Lot that aj^pears in the schedule are copied into 
the next step fields. If the status is WAITING or the status is RUNNING and the 
current step equals the first one found in the^hedule, operseqval is set to the seqnum 
of the row in the schedule. Otherwise, a RUNNING lot whose current step does not 
equal the first step in the schedule has operseqval set to 1 . The Area corresponding to 
the stnfam is placed in the areaname ocmextareaname fields. It is obtained from datal 
field in stnfamdef. When this is complete, the current schedule is changed by setting 
the new schedule name in the curremschedule/fields in the system-data table. 



a) If the lot status is WAITING, the next step fields will be set to the next 
scheduled step. If the^status is RUNNING, the next step fields will be set to 
the next scheduled step which will normally be the one that is running, i.e. the 
same as the current step. This sets lotstat up as though it were in the steady 
state. / 

b) If a lot is not inane schedule, it will be copied to Lotstat with operseqval set to 
0 indicating ttfat there is no schedule. 

There is no provision to send lots that are in the Hold state. 

The T2 data extraction in PROMIS is not logically instantaneous. This means that the 
status of lots dan change between the time the extraction is started and the time it 
completes. It a trackin/out is performed during this time, they should be applied to the 
resulting schedule if they happen after the affected lot was extracted, but ignored if 
they happen after T2 start but before the lot is extracted. There is no explicit way of 
knowina'which is which so a certain degree of robustness must be builtin and it must 
be understood that there may occasionally be a few lots that are out of step with 
PRODIS until a transaction is performed against them. 

The/e will be a delay from between the start of the T2 data extraction and the 
installation of the resulting new schedule. Trackin/out generated during this time 
must be applied to both the current status and the new status when the new schedule is 
installed. 

In the "steady state" Trackin/out transactions will be processed but left in the buffer 
table. They will be marked with the current schedule name. New transactions will 
have the schedule name set to the empty string. The Trackin/out DB Procedure will 



This means that: 
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only process records that do not have this field set to the current schedule name so a 
record will only be processed once for a given schedule. / 

At T2, a new set of WIP data will be extracted along with the start time of the 
extraction. This data will be placed into Orderstat. ATI records in the transaction 
buffer table that have a time before the T2 downloads start which have been processed 
for the current schedule, will be deleted because they cannot possibly be relevant to 
the new T2 data. / f/^ 



The schedule will then be run using the data ifi orderstat: Meanwhile transactions will 
continue to be processed to update Lotstat zts described above for the "steady state". 

When the schedule is complete it will Deinstalled in as - schedule under a new name. 
The Orderstat records will overwrite tat Lotstat records and the current schedule name 
will be changed to the new one. The/DB procedure will be triggered to process the 
transaction buffer table. / 

The existing records in the transaction buffer table will have been marked with the 
name of the previous scheduleyriot the new current one. Therefore, they will all be 
reprocessed against the currem schedule which will bring the status up to date with all 
the transactions that have occurred since the start of the T2 extraction. The records 
will be marked with the new schedule name. They will be deleted when the next T2 
download arrives. / 

This protocol closes almost all of the gaps. The only issue is that there could be a few 
extra transactions tha/ are not required. This will happen for lots that have 
transactions after thef start of the 

T2 download but>6efore they are extracted and put into the T2 dataset. If the DB 
client cannot finn a match for a transaction, no status update will take place, it will 
just be markedyas processed. The protocol will not miss transactions, it may just have 
a few extras. / 

WIP Transaction Processing 

The PRQMIS transaction messages will be sent over the TIB message bus from the 
VAX toyfhe HP. There will be a TIB adapter on the HP to receive the messages. The 
records/will be written to a DB buffer table. 

A DB procedure will be fired by a DB trigger every time a record is inserted into the 
buffer table, it will read the next record from the table and then update the dispatch 
list/to reflect the new status. It will process every record in the buffer that does not 
hsfve the Schedule_processed field set to the currently active schedule. Records are 
processed in time order. 




Each message from PROMIS will contain the following information. 
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WlPtransactionbuffer 
Field 
Lot 

CurStep 

Device 

Type 

Equipmentld 
EquipmentType 
EquipmentProgld 
Qty 

Operatorld 

Transtime 

ScheduIe_processed 

Action 



Steady State 



Comments 
Lot Id 

Device 

I/O/A/N for trackin/out/al; 
Stn 

Stnfam 



5rt/new lot 




current qty in lot 
not used 

Time of transaction 

Schedule against which this was processed 
Null when placed into the buffer. 
A trace fi^id that is populated when a transaction is 
processed. Null when transaction is placed in the buffer 



Note: Sony is responsible for the/TIB and import process. 



In the steady state, when theZx>tstat table has been created, the relevant Lotstat fields 
will be as indicated and the/PROMIS transactions will be processed as follows: 

Current status = RUNNING 



lotuserstat 
lotqty 
stnfam 
stn 

areaname 
opername 
setup 
stage 
nextstn 
nextstnfa 
nextopername 
nextsecup 
nextstage 
nexfareaname 
onerseqval 



''RUNNING', 
current lot qty 

equipment type of current step 

current equipment id 

area of current stnfam 

current step 

current setup 

current stage 

n/a 

n/a 

n/a 

n/a 

n/a 

n/a 

seqnum of this step record in the current schedule (as - 
schedule). This will be the first occurrence of the step (i.e. if 
there is a setup and process, it will be the setup) 



Current status WATTING 
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lotuserstat 
lotqty 
stnfam 
stn 

areaname 

opername 

setup 

stage 

nextstn 

nextstnfam 

nextopername 

nextsetup 

nextstage 

nextareaname 

operseqval 



WAITING' 
current lot qty 
n/a 
n/a 
n/a 
n/a 
n/a 
n/a 

next scheduled equipment id 
next scheduled equipment type 
next scheduled step> 
next scheduled equipment program id 
next scheduled s6ge 
next scheduleoVarea 

seqnum of n^xt step record in the current schedule (as- 
schedule). 




If operseqval is 0, the lot was Zither not scheduled or has moved past the end of the 
schedule. In this case, the lot will move as directed by PROMIS and not reference the 
schedule. 



Transactions 



5.2.1 0=Trackout 

PROMIS indicated the next step that it expects to perform from its routing. This 
should be the same as the schedule assuming that the schedule has been run far 
enough out anci that it has not chosen an alternative step. The system must calculate 
the next step/o be performed so that it can be displayed on the dispatch list. It will 
search ahead from the current position (operseqval) in the schedule to find the next 
expected s/ep. This is the next step that is different to the current one in the schedule ( 
this gets over multiple rows for setup/process etc.) and that is not at a Wet station. 
The respiting step should be the same as PROMIS. If it is not, the step from the 
schedule will be used. The next step fields will be set up to the next step as indicated 
by th/ schedule. The next stage, setup and stnfam are found by fading the step in 
operaef The operseqval will be set to point to the next step in the schedule. 



If/there is no schedule (operseqval = 0), or the trackout was from the last step in the 
:hedule for this lot, the next step fields will be set to whatever PROMIS indicated, 
le next stage, stnfam and setup will be found from operdef. The next stn will be set 
to blank because the routing indicates only the stnfam. If the step cannot be found in 
the normal route, the stage, stnfam and setup will be set to blank. Once the step 
indicated by PROMIS cannot be found in the schedule, operseqval will be set to zero 
and the system will stop attempting to show the schedule for this Lot, it will be 
tracked to match whatever PROMIS indicates in the transactions. 
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If the step value is FINISH, SCRAP, NOSTEP then lot tracking will stop. The lot will 
remain in Lotstat, its status will be set to the step value (FINISH, SCRAP, NOSTEP) 
and operseqval to 0. Future transactions against this lot wjlf be ignored. The current 
and next step fields will not be altered. 

I=Trackin 

The lot should currently be in the WATTING, QOEUEHOLD, TRACKOUTHOLD 
states when a Trackin is received. The lot wi IT always be tracked into the step 
indicated by PROMIS. The 'current* fields in Lotstat will be altered to reflect this. 

The step that it has been tracked into should be the same as the next scheduled step 
indicated in Lotstat. The operseqval h* Lotstat should already be pointing to this step 
because it was set up during the tracj&ut so will not change. The next stage will be 
copied from the next fields to the current fields. The current stn, stnfam, setup will be 
those sent from PROMIS. / 

If the step that the lot is tracked into is not what was expected , the schedule will be 
searched for the step that iLwas tracked into. If it is found the operseqval field in 
Lotstat will be updated toyftiat value. The stage will be obtained[ from the 
corresponding step in theroute. The current stn, stnfam, setup will be those sent from 
PROMIS. / 

If the step is not in ine schedule, the stage will be found from the current route for the 
step that was sent/ If the step cannot be found the stage will be blank. The current 
stn, stnfam, setup will be those sent from PROMIS. This logic will always be 
performed if there is no schedule for the lot (operseqval = 0). 

A=Abort / 

The lot n/ust be in the RUNNING state. It will remain at the current step but its state 
will be /hanged to WAITING. No other fields will be changed. The lot will then 
appea/ as a WAITING lot but it will use the next step fields. The next step will be the 
samaras the one just aborted not what the schedule predicted. 

H=Ho!d / 

PROMIS will indicate the step in the message 

/ If the step is the same as the current step 
/ lotuserstat = TRACKOUTHOLD 

/ else 

/ lotuserstat = QUEUEHOLD 

/ end if 
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The other fields will be setup as though it was a trackout. The^fext transaction that 
could be received for this lot is a Trackin to the next step, aljiiough the PROMIS 
operator has to perform other actions before this can nappe 



N=New Lot 



10 



15 



La 

s 



20 



25 



30 



A new lot record will be created in Lotstat. The k5t will not be added to Orderstat. By 
definition, it will not have an schedule. The ro^te will be found from the 
device/partdef record and then the other fielgX looked up in the route if they exist. 
The fields will be set up as follows: 



lotuserstat 
lotqty 
stnfam 
stn 

areaname 
opername 
setup 
stage 
nextstn 
nextstnfam 
nextopername 
nextsetup 
nextstage 
nextareaname 
operseqval 
partname 
routename 
priority 3 



Logging Actions 




WAITING' 
current lot qty y 
n/a 
n/ii 
n/a 
n/a 
n/a 
n/a 



stnfam from route if exists 
lext step from transaction 
current setup from route if exists 
next stage from route if exists 
next area from stnfamdef 
0 

from the active partdef record for this device 
from the active partdef record for this device 
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To aid/in debugging an extra field called 'action* has been added to the 
wiptpansactionbuffer table. This field will be updated when the transaction is 
processed. The wiptransactionbuffer records are deleted at T2, so the log is not 
lanent. 



Notes* 
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If a transaction is received that has no match, apart from the situation described above, 
it will not update a Lotstat and will effectively be ignored. It will remain in the buffer 
in case it applies to the next T2 download, i.e. if operators do steps in a different 
sequence to that of the schedule, which directly reflects the routing, the status of that 
Lot will not be synchronized between the database and PROMIS. 



55 



Docket No. 80,000-056 
SOA-195 



Schedule Display 

Schedule Display Screen 

The Schedule/Dispatch List display will be created usn*g ORACLE Forms tool and 
will be an HP/UX process. It is a report (i.e. has no pB update capability) that the 
user can filter by: 



Equipment ID (Stn) 

Equipment Type (Stnfam) 

Cluster 

Area 

Lot 

The columns on the screen will be: 




Name 


/ Column Width 


Equipment id (Stn) / 


f 4 


Priority of lot / 


1 


Lot id / 


12 


Lot Type / 


2 


Scheduled start time 


18* 


Equipment Prog Yd 


12 


Stage / 


10 


Device / 


12 


Qty of wafersrin lot 


2 



♦assumes dd/mm/^y hh:mm:ss. All that is really needed is day/hour/min so some 
adjustment may pe made to this. 

All Lots with si status of WAITING will appear first followed by all Lots with a status 
of RUNNING. Rows will be ordered by scheduled start time within the WAITING 
group and he actual start time within the RUNNING group. The next sort order will 
be priority/ Earliest times will be higher on the screen. 

Other information: 

Time that schedule was created 
Time that the last refresh was performed 

Ther rows will be color coded to reflect the status and/or priority of the lot. It may be 
necessary to trim some of these fields or use horizontal scrolling if the real-estate is 

*ht. A similar screen will also be available on the DB Client. The user will be able 
io look upstream by selecting the appropriate stnfam view. 

There will be a refresh key so that the operator can refresh the screen with the latest 
data without changing the selection. 
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Color coding scheme: 



Priority 

1-2 

1-2 

3-5 

3-5 



Run/Wait Foreground Background 



Run 
Wait 
Run 
Wait 



White 
Red 
Black 
Black 



Red 

White/ligh) 
Green 
White/^ght 



The sequence of events that the operator will usorto process a lot is approximately: 

a) Select the dispatch list for the equipment id that needs work. 

b) Note the next lots scheduled and gar and find the lot 

c) Return to the equipment with the/Lot and perform the normal PROMIS Track- 
in procedure. 

d) The lotstat DB table will be undated from a message from PROMIS 




Invoking the Schedule Display 



The schedule will be displayed on the same X-windows terminal as the PROMIS 
interface except that it will/use a different session driven from the HP. The operator 
will be able to switch between the two sessions using the mouse or by Alt-Shift as 
they do with the cell controller. 

Sony will be responsive for this function. 

TACT Data Algorithms 

TACT Table 

The TACT date is used to calculate Ptime, Ptper, Xpiece, Setup, Unsetup for each 
operation/step in the route file that is passed to AS for use in the simulation. The 
TACT time/ are independent of the route and are dependent on the equipment type 
and process being performed. The TACT data will be kept in a DB table. It will be 
maintainera manually and will not have automatic updates performed by the PROMIS 
data imrrort. 



syge 

^fecipeTitle 

>tnfam 
r EquipmentProgld 
reticleld 



Keys 

Primary Key 
Primary Key 
Primary Key 
Primary Key 
Primary Key 



Comment 
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useflag 

tO 

tl 

t21 

t22 

t23 

t24 

t25 

t3 

batchqty 

Comment 

Cycle 

CycleTO 

Machine 

MachineTO 

Ptime 

Stime 

UnsetupTime 

LapTime 

Tactid 



Times in floating pohrf mins 




Sum all T 
Cycle - TO 
(Sum all T)/batchqty 
Machine - TO/batchqty 
Calculated by Algorithm 
Calculated by Algorithm 
Calculated by Algorithm 
Calculated by Algorithm 
0 if useflag=PRODUCTION or NEW. A 
unique value otherwise. 



Each record will have a/control flag that will have the following meanings: 
PRODUCTION Use for production calculations 
SAVE Save put do, not use in production 

NEW Record will be used in production but should be manually updated (only 
default tipnes) 

The calculated" times are all in minutes. 



Note: Calculated fields cannot be changed directly on the screen. They are 
recalculated when the argument fields on the same row are changed. 

Note, /there can be only one record for a given set of unique keys with a useflag of 
PRODUCTION or NEW. The DB keys are set up to prevent this from happening. 

Change History 

ivery time a change is made and saved to a record, a record will be created in the 
TACThist table which is a copy of the status record. Reports can be written to 
provide a history of all of the changes to a given TACT. History is created when a 
record is added or changed. 
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TACThist table 



Field 
Stage 

RecipeTitle 
Stnfam 

EQUIpmentProgld 

Reticleld 

EffectiveTime 

Userid 

Badge 

Comment 

tO 

tl 

t21 

t22 

t23 

t24 

t25 

t3 

Batchqty 
CycleTO 
Cycle 

MachineTO 
Machine 
Ptime 
Stime 
Unsetuptii 
LapTime 



Keys 

Primary Key 
Primary Key 
Primary Key 
Primary Key 
Primary Key 



Comment 



le change was made 
Jser making the change 
Badge/Username of user 
making the change 
Copied from the def table 
Times in floating point mins 




TACT Definition, 



Add New TACT records from Routes 

Therer will be a function that allows the user to scan the routes in the DB and 
automatically add entries for steps that have no TACT entry with a useflag of NEW or 
PRODUCTION, i.e. every step with a unique combination in of the following fields: 



stage 

Equipment type (stnfam) 
Equipment Program Id 
Recipe Title 
Reticle Id 
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will have an entry created in the TACT definition table if one does not already exist. 
This procedure could take a minute or more to run depending on the number of steps. 
The new TACTdef entries will be given the useflag of NEW. 

Delete unwanted TACT records by comparison with Routes 

There will be a function to delete all entries thabnave no corresponding steps in the 
routes. The criteria used is the same for adding reco/Cte. 



The Ptime, Setup, Unsetup and Lap tinies will be calculated by user defined 
algorithms based on values in the TACT table. The Xpiece will be decided based on 
the ptper copied from Stnfamdef. tfolank if ptper = piece, batch size from TACT if 
ptper = xpiece). There may be a/number of different algorithms in use depending on 
the type of equipment. The stnfamdef table will have new field that references the 
algorithms to be used to calculate the fields for TACT records for that stnfam. 

There will be a new table/that will hold the formulae for calculating the fields derived 
by these algorithms. The correct set of formulae to be applied to a given row on the 
TACT table will be found by looking up the TACTformula field in the corresponding 
stnfamdef record. T)(c calculated fields will be derived only from data in the 
TACTdef table recprd and the corresponding stnfamdef record. 

When the AS route file is derived from the database, the appropriate fields from the 
TACT records/that correspond to each step will be copied in. No calculation will be 
necessary as me results will already have been derived and stored in the TACTdef 
record. See/the section on running the schedule for details. 

TACT Expression Maintenance 

There jfcill be a special screen, TACT Formula Definition, that will allow Sony to 
create and maintain expressions/formulae to be used to calculate the fields in the 
TACTdef table. This screen will provide a "test 1 function so that the expression can 
be Verified to be syntactically correct and the results on a test dataset can be viewed. 

Each expression set will be given a name which can them be referenced by the 
Stnfamdef field TACT function. There will actually by four expressions in an 
/ expression set to calculate the TACTdef fields ptime, stime, unsetuptime, laptime. 

/ The expressions can include any field in the TACTdef record plus any appropriate 
/ field in the associated stnfamdef record. Constants can also be used. 

/ The screen will allow the user to select the formula to be edited from a the list of 
/ current formulae or to add a new one. There will be fields for each of the four 



Expressions 




60 



Docket No. 80,000-056 
SOA-195 



algorithms. The user clicks on the field to be changed and thernnakes modifications 
using normal editing. / 

There will be a single record ( 1 row) DW to represent each column of the TACT 
definition. The user may fill in the fields with, any vatfd set of numbers and then click 
"test 'to run the algorithm against the data and checMhat the expression is valid and 
that the answers are correct. Default values will he placed in the test data when the 
screen is opened. / 

When a formula is changed, the affected TACTdef rows must be recalculated for it to 
have any effect. The user can do this by gcftng to the TACTdef screen and 
regenerating the appropriate records. Fo/ convenience, there will be! a button on the 
TACT Formula Definition that will automatically invoke the TACTdef screen, run the 
regeneration function and close the sofeen agai 

Stnfam Definition / 

The Stnfam Definition Screen /llows the user to specify the formula set that will be 
used to calculate the TACT times for steps using that Stnfam (Equipment Type). If 
the user changes the formum to be used for a given stnfam, all the TACT times for 
that stnfam must be recalculated by opening the TACT Definition or TACT Formula 
Definition screens and regenerating the TACT times. 

Kanban Worksheet / 

This screen will provide the user with a method of generating Kanban points using the 
method of assigning kanban s based on amount of processing time required for 
production, e.g. Joy having a kanban stage be a group of steps that can be done in a 24 
hr period. The/screen will generate records in the Kanbandef and KanbanXref tables. 
There will beya new screen on the DB Client that will work as follows: 

The user will be able to adjust the following values which will be used to calculate 
values inythe derived columns. 



Name / Default 

Multiplier 1 

Required number of wafers out none 

Iriterval (days) 1 

Standard lot size 25 

Plan days in the month 30 



The user will retrieve a route from the route selection DDDW. Only routes that are 
associated with a part that has a non-null device can be selected because the 
KanbanXref table is keyed by device. 
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When the user has specified these parameters a grid with Jne following columns will 
be displayed: 



Stage 
Step 

Equipment Prog Id 
Lap time 
Target Lap time 
Cumulative Target Days 
Standard WIP 

Standard WIP in lots 
Cumulative Lots 
Kanban qty 
Manager Factor 
Adjusted Kanban qty 
Kanban name 
Kanban markers 



PROMIS stage 
Step 

Calculated froirf TACT (hrs) 
Lap Time*Moltiplier/24 (days) 
Ceiling(Surn(Target Lap Time)) 
Target*Daily wafer throughput 

(Daily throughput = Req wafers out/Plan days in month) 
Standard WIP/Standard Lot size 
Running total of Standard WIP lots 
sejebelow 

iput by user. Defaults to I 
'Kanban qty * Manager Factor 
see below 

Indication of whepe the kanban stages are currently 
configured 




The following display only fields are also included: 

Device 
Active Flag 
Number of Steps 
Number ofyKanban Stages 

When th/ route is displayed, the current kanban stages for that device will be shown 
by setting the indicators automatically. This information is taken from the 
KanbanXref table, not the route table. 

The/iser can automatically set the kanban stages based on the Interval. The system 
will scan down the steps and set the kanban stages at the points where the Cumulative 
Target Days column changes to the next Interval increment (e.g. if the Interval is 3, 
le first Kanban stage will start at the first step and end on the last step that has a 
/alue of 3. The next stage will start on the first step that has a value of 4 etc. 

However, some adjustment should be made so that kanban stages do not start in the 
middle of stages or other logical points in production. The user will be able to place 
pointers on rows by simply clicking there. He may place as many pointers as he 
wishes. The system will automatically calculate the kanban qty based on the kanban 
stages. This is the number of lots that can be in process at that kanban stage at any 
time. The user will be able to manually override these numbers. 
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There is a column on the right hand side of the DataWindow that th€ user clicks on to 
set pointers. This column is a separate DataWindow and is always there even if the 
main DataWindow is horizontally scrolled. The begin and end/of a kanban stage is 
indicated by a green or red arrow. If the stage is a single step a split green red arrow is 
used. The user sets kanban stages as follows: 



Click on row 
Shift-click on cow 
Click on row/to make it a start of a stage 
Shift click j6n same row to make it an end also 
Clicking /5n a row^with any marker will move 
the marjfer 




Begin kanban stage 

End kanban stage 

Single step is a kanban stage 

Remove marker 



When the kanban stages have been determined, the user clicks the Calculate button 
which will create Kanban names for eacn stage and calculate kanban quantities 
(Kanban qty). The Adjusted Kanban ouantity is calculated by (Kanban qty * Manager 
Factor). The Manager Factor can be/set for each Kanban by the user and is defaulted 
to 1 . The user may alter the Kanbaji stage names if desired. 

The user accepts the new kanbarf design by clicking the Save Kanban button which 
will populate the KanbanXref /able as described above and overwrite any existing 
KanbanXref records for this route. It will also create records in the Kanbandef table. 
It will attempt to delete any/previous entries from the Kanbandef table but this is not 
always possible due to the/keys, so some periodic maintenance to remove unused 
entries may be necessary/ 

The user can then apnfy the new kanbans to all routes in the current model for the 
device by clicking ttye Update Routes button. 

A new Kanban wifl be generated for this route by creating records in the Kanbandef 
table with the Kanban name of M K - <Device> - N". The kanban names will be 
created as defined above. Any existing records with this Kanban. name will be 
deleted. The welds in a new Kanban record will be populated as follows: 



Kantian 

inbantype 
W^anbanatt 

canbanrule 
^kanbanqty 
AWkanabanqty 
Pkanbantype 
Pkanbanatt 
Pkanbanrule 



K - <Device>-N 
Lot 

Anumpieces (default) 
rulek_FIFO (default) 
Adjusted Kanban Qty 
1 

Lot 

blank (default) 
blank: (default) 



Tfte "All Steps" button will automatically make every step a kanban stage and set all 
the indicators appropriately. This is equivalent to the user setting them all by hand 
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+ 




and then clicking the Calculate button. The user must still elicit the Generate Kanban 
button and Update Route button to actually change the database. 



The Clear button will clear all of the kanban indicators 
on the database. 



>n the screen but has no effect 



A Kanban stage cannot start on an alternative stef$ and alternative steps must be in the 
same stage as their 'master'. This will be taken/into account when automatically 
generating stages. The Target Lap Time wilboe set to 0 for all alternative steps. 

Note: This design does not have an additional table to store the calculations. 
When the screen is invoked, the values Mill be determined from the KanbanXref 
and Routedef tables. The advantage pi this is that there is one less table to 
maintain and that the current data will be 



Stage Definition 




There will be a new table that obntains the v^Hd stage names and the sequence number 
of the step in the route. This Jrable can be populated through the Stage Definition 
screen. Each operation is associated with a stage. That stage should appear in the 
Stagedef table. 

Stagedef will be model independent. A stage is unique for a device. The same stage 
name in the two different routings for the same device is the same stage. The same 
stage name in routines for two different devices will not necessarily be the same. For 
simplicity, stage na/nes are defined to be unique within a route regardless of Device. 

The Stagedef tahie will be maintained by a maintenance screen.. There will be a 
refresh button mat will delete the current records from this table and then refresh the 
table by scanning all the routes in the current model to create a list of the unique stage 
names for each device from the currently active route. This should only be performed 
on the Production model, the sequence values from the first step in each stage will 
also be stored. 



Stagedef 



7 ield Name 



Stage 
Route 
Seqval 

Commor! Database 



Keys 

Primary Key 
Primary Key 



Comments 



Seqval of 1st step in stage 



/Some of the data in the Schedule database will be copied to the Common Database at 
a "snapshot" time. The structure of the tables in which the data resides and - 4 he-fi#14^ 
names an d4 ypcs i3 described in th e appendix^ 
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10 



15 



20 



Table 


Comment 


StnfamDef 


Equipment Type 


StnDef 


Equipment Id 


PartDef 


Device 


RouteDef 


Master Route record 


OperDef 


Step records for routes 


StageDef* 


List of valid stages 


TACTdef* 


TACT data / 


OrderStat 


WIP/Lot status / 




* Tables are not model dependent 



The copying procedure must ensure that the data is consistent when it is copied and 
consider that an automatic download may be in progress. The routing information 
will be updated by a DB procedure. This procedure will lock the tables for writing at 
the moment it is to occur. To ensure Consistency, the process that copies the data to 
the Common DB should do the sam^. To avoid deadlocks, it is important that locking 
of multiple tables always occurs in/the same order. Most tables are model dependent 
and may have multiple models stored in them keyed by "modelname". We will 
designate a particular modelname to be used by the Common DB extraction. The 
simplest way to ensure no inconsistencies is simply to make a copy of the desired 
model and then copy that. CJopy model is a single command in the DB Client. 
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30 
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Locking Order 

Equipment 

StnDef 
StnfamDef 

Route 

StageDef 
OperDef/ 
RouteD/f 

Devices 

PartQef 

WIP 

OrtferStat 

TACT 

factDef 



40 AutoSched Model Changes 



45 



The/current Sony model will not be sufficient to run the data from PROMIS. A 
number of customizations will be needed beyond those that have already been 
implemented. Documentation of the changes and the install procedure will be 
provided. The changes made by ASI will need a number of custom fields. ASI will 
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use the fields starting from the highest number and working backwards to avoid 
conflict with existing customizations. / 



Splits 



Standard AS does not have any way of being told that a lot is currently split and will 
rejoin its parent at some point. This involves a customization to add the split lot to its 
parent split linked lists. The splitname that wiLr be used for the combine step must be 
added to the split's load. The information wHf be passed to AS in custom fields in the 
Order file. / / f~\ 



The PM requirement is new and custom and will require AS model customizations. 
PM will be driven by a new custom table. 



The TACT table provides the Ptime and Xpiece values which are standard fields in 
AS. It also supplies the setup and unsetup times which are additional custom fields in 
the step records. / 



The current Agenda records are no longer needed because the setup and usetup time 
will be handled a/custom fields in the step records. 



In order to import the schedule, the format of this file must be altered by a custom user 
exit. / 

Haying fully described the preferred embodiments of the invention, variations and 
modifications may be employed without departing from the scope of the present invention. 
Accoraingly, the following claims should be studied to learn the true scope of the present 



PM Counts and Limits 




TACT 



Agenda 



.sen File 



invention. 
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